A conventional approach to a business intelligent (BI) system, which is also referred to as a business intelligence system, typically consists of populating a data repository which is managed using a database management system, such as a relational database management system (RDBMS), and then defining reports and other output using reporting and analysis tools, such as an online analytical processing (“OLAP”) tool, to report or provide analysis using the data stored in the data repository.
In such a conventional approach, a reporting tool is typically used to define the data items to be reported, and the level of detail that is to be reported for each data item in a report. In order to accommodate potential reporting and analysis requirements, the data repository is designed to include data items at a lowest level of detail. For example, assume that the data repository includes a data item that reflects detailed purchase data. In this example, for the data repository, the RDBMS includes a table, e.g., a purchase table, which includes a row for each purchase and has column for the purchase amount, together with columns that provide information for use in aggregating the purchase amount, e.g., date of purchase, store in which purchase was made, product identifier, product line, etc.
While a report can be defined that outputs detailed information for each purchase, this type of report is typically not as useful as a report that aggregates the purchase information, such as revenue by store, daily revenue, revenue by product, revenue by product line, quarterly revenue, revenue by geographic region, for example. Unless an entity's BI requirements are known before a data repository is populated, the data repository must be designed to include a low level of detail in order to anticipate the entity's BI requirements. Methodologies such as the Kimball methodology provide general guidelines which define the type of data that should be stored in a data repository for a given application (e.g., finance, sales, human resources, etc.). However, use of such a methodology can lead to inefficiencies, since the methodology does not take into account the actual BI requirements of a specific entity. A practice of building a data repository without determining the actual data needs of an entity based on the entity's BI requirements can lead to an unnecessary expenditure of resources to design, store and maintain the data repository.
Building a conventional business intelligent (BI) system can involve sifting through large amounts of data to identify information to be stored in the data repository, extracting the identified information, and collecting the extracted information into the data repository (e.g., a data mart). Data might need to be collected from multiple sources into a data warehouse or data mart.
In practice, the process of building a BI system is an art. This practice is especially inefficient in view of the fact that the design and development of a BI system can involve a number of steps. The present inventors have determined that it can take a four-person team approximately three to six months to design and development a first version of a data mart. New teams are formed to build new data marts and systems independent of other development efforts. Examples of some of the steps involved in designing and developing a BI system include: 1) identifying data to be stored in the data repository (e.g., using the Kimball methodology), 2) tagging data for collection, 3) loading the data into a data warehouse and aggregating multiple data sources, 4) aggregating and extracting data from the data warehouse to flat files, for importation into a data mart, 5) loading the data from the flat files into the data mart, 6) designing a base-line schema for aggregation files, 7) designing a schema and the objects for reporting, 8) designing reporting and presentation layout, and 9) data validation and error checking.
Implementation typically involves either writing code manually, and/or using commercial tools to load data. Different data marts are often built for different departments in the same company, or for different reporting/analysis tools. Since each system is designed and developed independently, such that there is no uniformity across systems, efforts in the design, development, implementation and maintenance of multiple data warehouses/marts are duplicated, which can negatively impact a business. In addition, it is difficult to determine the capabilities (e.g., for reporting and analysis) of each system, thereby making it difficult to build from the current capabilities of an existing system when designing a new system. Further, efforts to maintain and enhance each of the independently-developed data marts and systems are performed independently, thereby adding to costs associated with a BI system.